home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000137_connolly@pixel.convex.com _Mon Jun 22 21:39:12 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  11KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA21341; Mon, 22 Jun 92 21:39:12 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA19580; Mon, 22 Jun 92 21:39:28 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA12765; Mon, 22 Jun 92 14:38:42 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA17202; Mon, 22 Jun 92 14:38:27 -0500
  10. Message-Id: <9206221938.AA17202@pixel.convex.com>
  11. To: raisch@cthulhu.control.com (Robert Raisch)
  12. Cc: jfg@dxcern.cern.ch, www-talk@nxoc01.cern.ch
  13. Subject: Re: Links, Types and Documents (Third time's a charm) 
  14. In-Reply-To: Your message of "Mon, 22 Jun 92 13:30:55 EDT."
  15.              <9206221730.AA04308@control.com> 
  16. Date: Mon, 22 Jun 92 14:38:26 CDT
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. ><!-- 
  21. >
  22. >  I first posted this some weeks ago on the 'www-interest' list, and 
  23. >  received only one reply, (complementing me on my reference to Rexx.)
  24. >
  25. I keep my copy of this posting handy and I check lots of ideas against it.
  26.  
  27. >  I really had hoped that this post would start an interesting discussion
  28. >  on the topics I address, specifically the ideas of 'attention links' 
  29. >  'user documents' and 'transparent documents'.
  30. >
  31. I don't have any well defined systems (implementations or just specs.)
  32. that address these issues. WWW is headed in this direction, but it's
  33. a long way off.
  34.  
  35. >  Are these ideas so obvious that they merit no discussion whatsoever?
  36. >
  37. No, it's more like they're so novel we haven't thought seriously enough
  38. to comment yet.
  39.  
  40. ><Query>
  41. >One of the missing pieces here is the ability of creating new h-texts, and
  42. >adding new links to old h-texts.
  43. >
  44. >Hypertext, and like systems, are of limited use if they do not support
  45. >collaboration.  I feel that this is a VERY important point.
  46. >
  47. >When might we expect extensions to WWW that support collaboration?
  48. ></Query>
  49.  
  50. You might look to Andrew for a more mature system in these regards.
  51. While I think Andrew is a great breeding ground for ideas, I think
  52. the resulting technology is too off-beat (for example, they implemented
  53. their own object-oriented C preprocessor, and now C++ has come along
  54. and writing Andrew code looks like a pain in comparison).
  55.  
  56. I'm toying with the idea of a FrameMaker inset editor to interface
  57. Frame's direct-manipulation editing capabilities with global
  58. hypertext on the internet. I shouldn't even mention it until I have
  59. some sort of implementation, but it's an idea...
  60.  
  61. >I have a few recommendations regarding new link types in WWW.  This is based
  62. >on thinking about hyper-applications for almost 15 years, (ever since I 
  63. >first had the pleasure of hearing Ted Nelson speak in 1977.)
  64. >
  65. >Please keep in mind that these are 'front end' issues.  They should not
  66. >affect the manner in which documents are stored.
  67. >
  68. Well, we should be careful not to store documents in a way that
  69. conflicts with these useful concepts.
  70.  
  71.  
  72. >------------------
  73. >
  74. >There are 4 'minimal' link types which, I believe, a true hypertext applicatio
  75. n
  76. >*must* support.
  77. >
  78. >    1.    Replacement
  79. >            -- when activated, replaces the current document
  80. >               with a new document, (this is what WWW offers
  81. >               today).
  82. >
  83. FrameMaker: gotolink
  84. GNU Info: menus, notes
  85. WWW: <A HREF=...>
  86. EBT: link
  87.  
  88. >    2.    Annotation
  89. >            -- when activated, overlays a new document on the
  90. >               current document, partially obscuring the original.
  91. >               (An annotation must be dismissed by the reader.)
  92. >
  93. FrameMaker: openlink
  94. GNU Info: n/a
  95. WWW: n/a
  96. EBT: link window=new
  97.  
  98. >    3.    Inclusion
  99. >            -- when the document is created, elements from other
  100. >               documents are collection to be included in the
  101. >               representation of the current document.  (Quotes)
  102. >               (This is a non-interactive link.  The user does
  103. >                not activate this link. It is activated before 
  104. >                the document is presented to the user.)
  105. >
  106. FrameMaker: import by reference (bitmapped graphics ONLY)
  107. GNU Info: n/a
  108. WWW: n/a
  109. EBT: n/a
  110.  
  111. >    4.    Expansion
  112. >            -- when activated, new information is added to the 
  113. >               current document, expanding the original scope.
  114. >
  115. FrameMaker: conditional text
  116. GNU Info: n/a
  117. WWW: n/a
  118. EBT: change stylesheets so that HIDE property changes
  119.  
  120. >
  121. >There are 3 further types which I believe are necessary to complete the
  122. >function paradigm.  (Of particular interest is the 'attention link'.)
  123. >
  124. >
  125. >    6.    Execution
  126. >
  127. >            -- when activated, some arbitrary function is performed
  128. .
  129. >               The point that was mentioned about the lack of an
  130. >               ubiquitious scripting language is well made.  Lisp
  131. >               is too arcane for most.  Shell languages are too
  132. >               platform specific.  What is needed is a simple
  133. >               to understand, freely available scripting platform.
  134. >               Although I hesitate to mention it, REXX might be
  135. >               a reasonable choice due to it's broad availability.
  136. >
  137. Ah... if you want commentary, state an arguable thesis. No one can argue
  138. against a platitude like "What is needed is a simple to undertand,
  139. freely available scripting platform." I vote for some brand of Lisp, perhaps
  140. XLisp or ELK.
  141.  
  142. But there's a larger issue: should documents be turing machines? Using SGML,
  143. it is a well defined problem to determine whether a document is valid. As
  144. soon as we allow documents to be programs (like TeX, nroff, or Lisp), we
  145. run into the halting problem and we lose any hope of converting documents
  146. from one representation to another. If a document is a program that, when run,
  147. conveys its content, then we lose the ability to use that content in any
  148. other way than the author originally intended.
  149.  
  150. >    5.    Attention   (a specialisation of the Execution type)
  151. >
  152. >            -- when the current document is modified (a link is
  153. >               added, or removed, or the document is merely read)
  154. >               a message is sent to the 'owner' of the attention
  155. >               link.  This message creates a new link in the 'user
  156. >               document' of the individual who placed the attention.
  157.  
  158. Hmmm... I need a clear explanation of the underlying model here. In the
  159. model in my mind, a "document" is never modified. But the functionality
  160. you describe is interesting. Certainly we want to be able to collect
  161. usage statistics.
  162.  
  163. >    7.    Collection  (a non-local specialisation of the Execution type)
  164. >
  165. >            -- when activated, a collection link leaves the current
  166. >               document, and 'travels' the docuverse, in search of
  167. >               other documents which satisfy it's internal criteria.
  168. >
  169. >               This is the concept of a 'knowbot'.
  170. >
  171. It looks like a query to me. I need either 1) a good definition of the
  172. capabilities of a knowbot, or 2) an implementation of a knowbot (any
  173. sort of hack will do) to get a feel for the functionality. Until
  174. then, it's just a very vague idea. Fortunately, there are some
  175. implementations of this idea: cron/find, WAIS, USENET news (kill files, etc.)
  176.  
  177. >
  178. >    Transparent Documents  --
  179. >
  180. >        a transparent document is one which a user creates locally,
  181. >        and that is a new representation of an existing document.
  182. >
  183. >        Transparent documents are used to create new local links on
  184. >        a document which I do not have permission to modify.
  185. >
  186. >        Transparent documents can then be made available to others,
  187. >        (published) just as a "regular" document is, thus facilitating
  188. >        the creation of new works from old.
  189. >
  190. This looks like a local copy of a document to me. No?
  191.  
  192. >    User Documents --
  193. >
  194. >        a user document is where I keep my "bookmarks", links to
  195. >        local documents, links to messages from others, links to
  196. >        my "attention" links, (see below).  User documents are where
  197. >        we, as navigators of the docuverse, are defined as individuals.
  198. >
  199. >        They are also where we can keep links to other user documents
  200. >        which have been permitted to view/modify my own local documents
  201. .
  202. >
  203. >        Another function of the User document is to collect users into
  204. >        an abstract group. (Thus, based on my membership in user 
  205. >        document 'Research Group', I am permitted access to materials
  206. >        'owned' by that group. Of course, messages sent to an abstract
  207. >        group then become available to all members of that group.)
  208. >
  209. >        (Please note that a User Document is nothing more or less than
  210. >         a collection of links, (as all documents are).)
  211. >
  212. Now we've opened up the whole PIM can of worms. Current implementations
  213. include mail user agents (MH, Elm), news readers (with their .newsrc and
  214. kill files, etc.) wais-questions, WWW home documents. I haven't looked
  215. at the hyperbole model, but I understand it addresses this issue at length.
  216.  
  217. >So.....
  218. >
  219. >    Scenerio:
  220. >
  221. I'd like to see how a MIME user agent would satisfy this scenario...
  222.  
  223. >        I start my session with my hypertext-application, and open 
  224. >        my user document.
  225. >
  226. I start my MIME UA.
  227.  
  228. >        I notice that 17 of my attention links have been activated 
  229. >        in the last day.
  230. >
  231. There are 17 mail messages (with certain tell-tale headers) in my inbox.
  232.  
  233. >        I select the most interesting and activate the link which
  234. >        it created in my personal user document.
  235. >
  236. I read the message. It's a message/external-body type message that points
  237. to an article in a USENET database at this site.
  238.  
  239. >        I am now reading an article which I previously linked
  240. that is, I had saved the article by creating a message/external-body
  241. type message in my mail box.
  242.  
  243. >        , and
  244. >        see that an annotation which I made some time ago
  245. i.e. my followup article
  246.  
  247. >         has been
  248. >        added to, by a colleague.
  249. >
  250. i.e. has been followed-up.
  251.  
  252. >        The comments are pertinant to my current work, so I create
  253. >        a new local 'transparent' document to mirror the original 
  254. >        work.  (Or use the 'transparent' document I may have created
  255. >        previously.)
  256. >
  257. I just save a reference to the news artile, as above, in a message/external-body
  258. type message.
  259.  
  260. >        On this new document, I make a few new annotations
  261.  
  262. i.e. I follow up to the document. It would be nice to be able to do
  263. some direct-manipulation style annotation to articles, ala FrameMaker.
  264.  
  265. >        and decide
  266. >        to made this new work available to the research group of which
  267. >        I am leader.  I place a link to it in the user document which
  268. >        represents my working group.
  269. >
  270. I mail a message/external-body style reference to the thread to the
  271. alias that represents my working group.
  272.  
  273. I really think that Internet Mail, Usenet News, and WAIS could be
  274. a great platform for CSCW. A MIME user agent that could make
  275. WAIS and NNTP queries and act as a FrameServer client would
  276. be a great start. If I have time, I'll try to cook something up.
  277.  
  278. Dan